<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Concept: Message Design</title>
<meta name="uma.type" content="Concept">
<meta name="uma.name" content="message_design">
<meta name="uma.presentationName" content="Message Design">
<meta name="element_type" content="concept">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="5.580979266831891E-307"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Concept: Message Design</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/concept.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This page describes the concept of message-based communication. It also discusses message exchange patterns and the relationship of the domain model to the message model. Design considerations for message granularity and message performance are also outlined.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../rup_soa_plugin/workproducts/soa_svce_model_message_BE931590.html" guid="{DD9F96C3-4D00-4441-951E-2674B9AEE1C6}">Message</a>
</li>
<li>
<a href="./../../../rup_soa_plugin/workproducts/soa_service_model_623494B9.html" guid="{E24679B7-19F1-483B-A1F1-578839C43888}">Service Model</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><h3>
    <a id="Introduction" name="Introduction">Introduction</a>
</h3>
<p>
    In most object-oriented programming languages, behavior invocation is based either upon method calls or message passing
    paradigms. C++ for example uses tables of function pointers to invoke the correct method. Smalltalk on the other hand
    passes messages whose receiver is evaluated at execution time. Service-oriented solutions are inherently message based
    and while bindings to programming languages may present method based interfaces for clients, this is not the reality of
    communication with or between services. Another facet of service messaging is that more and more services are being
    developed with asynchronous interfaces as opposed to the fundamentally synchronous nature of method calls.
</p>
<p>
    In the enterprise integration arena, one class of technology has been used with success for a number of years: Message
    Oriented Middleware (or MOM). This set of technologies is manifest in products such as queue managers and message
    brokers. It has provided IT organizations with a flexible, scalable, and robust method for loosely connecting
    applications.
</p>
<p>
    It has been noted that Service-Oriented Architecture (SOA) is an evolution of component-based development. In some
    respects this evolution takes into account many of the lessons learned from the success of MOM: how to loosely couple
    systems effectively. The MOM infrastructure provides the following characteristics that allow communicating systems to
    evolve independently.
</p>
<ul>
    <li>
        <b>Message Queuing,</b> for reliable delivery of messages even in the event of network or system failures.
    </li>
    <li>
        <b>Message Routing,</b> both in terms of routing around the network for performance and reliability and advanced
        routing based on the message content.
    </li>
    <li>
        <b>Message Transformation,</b> so that a calling service can post a request for a "product" when the receiving
        service can accepts requests for "items."
    </li>
    <li>
        <b>Message Adapters,</b> to allow systems that were not originally developed with MOM interfaces to be addressed by
        MOM aware services.
    </li>
</ul>
<h3>
    <a id="MEP" name="MEP">Message Exchange Patterns</a>
</h3>
<p>
    When thinking about messages, there is a natural tendency to consider them to be simply the parameters to operations.
    This is made more likely because the UML representation of services uses operations with parameters and the Web
    Services Description Language (WSDL 1.1) uses a similar approach. However, when thinking in terms of <a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_service_1EE4C96C.html" guid="{FF65B0A2-6C53-4F01-9727-AACDB0D542C8}"><i>Services</i></a> and <a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_spec_37E89A91.html" guid="{20F06B5E-95D5-422C-AB68-7C213D28533A}"><i>Service Specifications</i></a>, it is more helpful to think in terms
    of messages as reusable elements that are either produced by or used/consumed by a service operation. In services
    parlance, the operation simply becomes a <i>message exchange</i>, albeit a named exchange on a service that is
    distinguishable from another exchange that may use the same input and output messages.
</p>
<p>
    The notion of <i>message exchange pattern</i>s has been of interest in the Web services standards world, as a part of
    the analysis of the use of services in developing standards to support their specification. A message exchange pattern
    names a particular combination of produced, used, or consumed message between two services (or between a service and a
    consumer) and provides a common vocabulary for service designers to describe operations on service specifications.
</p>
<p>
    The following lists common exchange patterns that can be used in the definition of service specifications. Such
    patterns are usually found during the modeling of <i><a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_collab_76358B24.html" guid="{9BBBE5B0-4D39-4555-9E20-0ADBD8327D29}">Service Collaborations</a></i>.
</p>
<p>
    <b>Synchronous Request/Response:</b> This is in effect a traditional method invocation where the service consumer sends
    a message to a service and then blocks waiting until a reply is received from the service.
</p>
<p align="center">
    <img height="91" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_choreography-01.gif"     width="262" border="0" />
</p>
<p>
    <b>One Way Message:</b> In this case, the consumer simply sends a message to the service, not waiting for or expecting
    a reply. This pattern can be considered an asynchronous method call with no reply type, meaning that the service
    consumer continues execution after the message is sent, rather than waiting for the service to process the message.
</p>
<p align="center">
    <img height="91" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_choreography-02.gif"     width="250" border="0" />
</p>
<p>
    <b>Notification:</b> In this case, the service is responsible for sending messages back to the consumer (usually
    another service). To accomplish this the consumer has to have somehow registered with the service so that the service
    knows where to send the notification messages.
</p>
<p align="center">
    <img height="91" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_choreography-03.gif"     width="253" border="0" />
</p>
<p>
    <b>Asynchronous Request/Response:</b> This is a combination of the one-way message and notification. The service
    consumer sends a message, including a reply-to address. When the service completes its processing, it calls the
    originator back. The fact that service consumers send the first message in an asynchronous manner does require them to
    keep track of all sent requests so that responses, when received from the service, can be correlated to the original
    request.
</p>
<p align="center">
    <img height="110" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_choreography-04.gif"     width="262" border="0" />
</p>
<p>
    <b>Publish/Subscribe</b>: Again this is a combination. A service consumer registers interest in a "topic" with a
    publication service. Other services or service consumers publish messages (send messages) to the publication service
    identifying the topic associated with the message. If the topic matches previously registered consumers, they are
    notified of the new message. In this case it is possible to very loosely couple the services participating. Any
    consumer or publisher only needs to know the location of the publication service and new consumers can be added to the
    solution without significant effort.
</p>
<p align="center">
    <img height="130" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_choreography-05.gif"     width="346" border="0" />
</p>
<h3>
    <a id="Domain_Modeling" name="Domain_Modeling">Connection with Domain Modeling</a>
</h3>
<p>
    In the concept <i><a class="elementLink" href="./../../../rup_soa_plugin/guidances/concepts/domain_design_77B2F855.html" guid="1.2602759670310655E-305">Domain Design</a></i>, the notion of domain modeling was outlined, similar to the notion of an analysis model or
    business-analysis model in representing core concepts from the business domain in a technology independent manner. It
    is clear that the messages used by services are technology aware (if not technology-specific in the case of XML Schema
    used for Web Services) in the same way the database schema used to store the domain data is technology specific within
    the service. In fact, we may consider the following relationship.
</p>
<p align="center">
    <img height="106" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_msg_design-01.gif"     width="246" border="0" />
</p>
<p>
    This demonstrates the relationship between the domain model used for discovery of the key domain elements and the
    message model as the realization of the domain model as a set of elements passed into and returned from services.
</p>
<p align="center">
    <img height="206" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_msg_design-02.gif"     width="435" border="0" />
</p>
<p>
    The following is a typical Java/component model where we can see the separation of the Interface from the Class and the
    inclusion of "accessor" functions to get and set the value of the state variables. This is a very common approach, but
    it has the disadvantage that, if the consumer and component are in different address spaces or on different machine,
    the cost of communicating each call is high in terms of accessing the entire state of any one component.
</p>
<p align="center">
    <img height="266" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_msg_design-03.gif"     width="737" border="0" />
</p>
<p>
    Another issue is the relationships between components, the notion that an Account has a set of Customers is difficult
    to develop in this style and usually ends up in managing lists of identifiers used to retrieve individual objects.
</p>
<p>
    In developing a service model we might use a <i><a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/tasks/identify_services_565F8B8A.html" guid="{0BF79161-A484-4C48-B72D-DA381DA05886}">data-driven service identification</a></i> approach leading to the
    specification of an AccountMgr service and a MeetingMgr service. The first service specification acts as the central
    location for managing all accounts and contacts. In fact, the core data model for the Customer Relationship Management
    (CRM) solutions was built using this and other services. The second service has been separated because it can be used
    by the CRM solutions and other solutions for booking meetings and it will interface with the enterprise Groupware
    applications.
</p>
<p>
    The following is a sample from the model; it shows the service specifications, the messages can be assumed from the
    domain model above.
</p>
<p align="center">
    <img height="134" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_msg_design-04.gif"     width="338" border="0" />
</p>
<h3>
    <a id="Message_Granularity" name="Message_Granularity">Message Granularity</a>
</h3>
<p>
    Services are intended to provide large-granularity operations. As such, the messages that flow in and out of such
    operations tend to be large-grained also. This concern was originally highlighted early in the deployment of Web
    Service solutions where the use of HTTP as a transport, SOAP as a protocol, and XML as a wire format tended to lead to
    relatively slow responses and very high bandwidth requirements. For example, consider a request for a stock quote from
    an service. A simple stock quote was often demonstrated in the early Web Services days. The ticker symbol is four
    characters and the response is a decimal number. In an RPC style, binary protocol we might expect that the message
    identifier might add some overhead, let's say 8 bytes, and so we could expect somewhere in the region of 8+4 for the
    request and 8+8 (for a high precision decimal) in response. With HTTP/SOAP, we might expect something of the following
    form:
</p>
<table width="100%" border="1">
    <tbody>
        <tr>
            <th width="50%">
                Request
            </th>
            <th width="50%">
                Response
            </th>
        </tr>
        <tr>
            <td valign="top" align="left" width="50%">
<pre>
SOAPAction: "http://www.webservicex.net/Quote"<br />

User-Agent: MyAgent 1.0<br />

Content-Type: text/xml; charset=UTF-8<br />

&lt;?xml version="1.0" encoding="UTF-8"?&gt;<br />

&lt;soap:Envelope<br />

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"<br />

xmlns:tns="http://www.webservicex.net/"&gt;<br />

xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;<br />

&lt;soap:Body&gt;<br />

&lt;tns:Quote&gt;<br />

&lt;tns:Symbol&gt;IBM&lt;/tns:Symbol&gt;<br />

&lt;/tns:Quote&gt;<br />

&lt;/soap:Body&gt;<br />

&lt;/soap:Envelope&gt;
</pre>
            </td>
            <td valign="top" align="left" width="50%">
<pre>
HTTP/1.1 200 OK<br />

X-Powered-By: ASP.NET<br />

Connection: close<br />

Content-Length: 522<br />

X-AspNet-Version: 1.1.4322<br />

Date: Mon, 21 Mar 2005 00:34:21 GMT<br />

Content-Type : text/xml; charset=utf-8<br />

Server : Microsoft-IIS/6.0Cache-Control: private, max-age=0<br />

&lt;?xml version="1.0" encoding="utf-8"?&gt;<br />

&lt;soap:Envelope<br />

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"&gt;<br />

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;<br />

xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;<br />

&lt;soap:Body&gt;<br />

&lt;QuoteResponse xmlns="http://www.webservicex.net/"&gt;<br />

&lt;Quote&gt;&lt;Last&gt;89.28&lt;/Last&gt;<br />

&lt;/Quote&gt;<br />

&lt;/QuoteResponse&gt;<br />

&lt;/soap:Body&gt;<br />

&lt;/soap:Envelope&gt;
</pre>
            </td>
        </tr>
    </tbody>
</table>
<p>
    Early adopters of Web Service Technology came to two conclusions. First, services were optimized for a small number of
    operations providing data as documents rather than the more complex style of traditional component models. This has the
    advantage of amortizing the overhead of the protocols across a bigger actual data payload. Also, between services in an
    enterprise, at least between services within the same solution, smaller,simpler protocol bindings were chosen and
    HTTP/SOAP was reserved for situations where it was necessary, such as interfacing to services outside the enterprise.
</p>
<p>
    This notion is not entirely new. Even in the component world, the Value Object pattern, or the J2EE Service Facade are
    both approaches to reduce the number of communications round-trips between client and server. Both use the notion of
    sending a complete copy of the component state to the client rather than using the traditional accessor functions. For
    services, we may also like to consider the fact that services are being developed that are more closely aligned with
    business models, especially business process models. As such, messages come to reflect common business documents in the
    same way EDI Transaction Sets (Electronic Data Interchange) represent business documents such as orders, invoices,
    shipping notices, and so on.
</p>
<h3>
    <a id="Message_Performance" name="Message_Performance">Message Performance Considerations</a>
</h3>
<p>
    In general, the use of large messages is valuable in overcoming communications performance, although in some cases the
    large data message can be a problem. For example, in the SOAP messages above, we saw how the message size, using HTTP,
    SOAP, and XML significantly increased the size of the data. This has been a complaint of early systems built using Web
    Services technologies. On the other hand, these issues have allowed us to learn some interesting lessons such as
    considering performance in terms of code performance, message design, and protocol choice as an early design activity.
</p>
<p>
    One important aspect to consider is that as we are moving large chunks of state from service to consumer or service to
    service, these messages actually represent stale snapshots of the service state. So, one of the considerations is to
    explicitly manage this "staleness" by identifying the time the data can be considered reliable or to "lease" it to the
    consumer such that it expires after some amount of time. For more information, see the white paper <i><a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/guidances/whitepapers/soa_cbd_paper_5703509E.html" guid="2.48704851646278E-307">Using Service-Oriented Architecture and Component-Based Development to Build Web Service
    Applications</a></i>.
</p>
<p>
    Another topic that has to be considered is the caching of content. Caching is usually a concern that is dealt with as a
    performance optimization for applications, but in an service-oriented solution, the distributed nature and
    message-based communication lends itself well to the insertion of caches between consumers and services. These caches
    are not the typical database caches used for optimizing queries, but more like caches used in web servers and web
    proxies. In fact, in the case of Web Services using HTTP and SOAP, these proxies may be used as caches to serve up
    service responses in certain situations.
</p>
<p>
    The issues however, in regard to the use of any cache, are really how the cache understands the policies used to serve
    content from the cache and how a service can invalidate the cache. The technical infrastructure used to host and manage
    deployed services should provide caching capabilities. One area of service policy we expect to see in the future is the
    provision of cache management information.
</p></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright">Copyright &copy; 2008 版权所有 东软集团股份有限公司&nbsp; 联系邮箱:<a href="mailto:tcoe@neusoft.com">tcoe@neusoft.com</a></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
